The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS is defined in the 3GPP Specification 23.228.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS 3 fits into the mobile network architecture in the case of a GPRS/PS access network. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer, or traffic plane and through which signals are directed to/from user terminals accessing the network. The GPRS network includes various GPRS Support Nodes (GSNs) 2a, 2b. A gateway GPRS support node (GGSN) 2a acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). A Serving GPRS Support Node (SGSN) 2b keeps track of the location of an individual Mobile Terminal and performs security functions and access control. Access to the IMS 3 by IMS subscribers is performed through an IP-Connectivity Access Network (IP-CAN). In FIG. 1 the IP-CAN is a GPRS network including entities linking the user equipment to the IMS 3 via the connectivity layer 1.
The IMS 3 includes a core network 3a, which operates over the Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 include Serving CSCFs (S-CSCF) and Proxy CSCFs (P-CSCF), which operate as SIP proxies within the IMS in the middle, Control Layer.
At the top is the Application Layer 6, which includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality. Application Servers 7 provide services to end-users on a session-by-session basis, and may be connected as an end-point to a single user, or “linked in” to a session between two or more users. Certain Application Servers 7 will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server 7).
IMS relies on Internet Protocol (IP) as a transport technology. Using IP for voice communications, however, presents some challenges, especially in the mobile community where Voice Over IP (VoIP) enabled packet switched (PS) bearers may not always be available. To allow operators to start offering IMS-based services while voice enabled PS-bearers are being built out, the industry has developed solutions that use existing Circuit Switched (CS) networks to access IMS services. These solutions are referred to as IMS Centralized Services (ICS). ICS is described in 3GPP TS 23.292 and is also the name of the Work Item in 3GPP Release 8 addressing these matters. ICS allows a User Equipment (UE) to connect to a CS access network and to have access to Multimedia Telephony services.
Referring to FIG. 2, a UE 8 can access an MSC Server 9 via a CS Access network 10. It also accesses a CSCF 5 via a Gm reference point, and a Service Centralization and Continuity Application Server (SCC AS) 11 via a Gm reference point. SIP is used to perform service control between the ICS UE 8 and the SCC AS 11 over the Gm interface. For a speech service, the ICS UE 8 can use its CS access to transfer voice media. The ICS specification defines how it is possible to use a CS bearer controlled via the Gm interface.
When a SCC AS 11 receives an incoming call, or other type of session request (or other type of media component, such as video), it will select an access domain. The procedures specified in TS 23.292 allow for CS access to be selected, but keep the provision of services entirely in the IMS. This can result in unnecessary routing of signalling and media.
For example, if a UE is accessing services via a CS access network (i.e. anchored on the CS domain), and receives a call from another UE, also anchored on CS, then the current ICS solution will force the call from the CS domain to the IMS to perform the Terminating-Access Domain Selection (T-ADS), and then route it back to the CS domain after detecting that the UE is anchored on CS. This is illustrated in FIG. 3. An originating CS-anchored UE 301 initiates a call/session with a terminating UE 302, which is registered in both the CS and IMS network domains. The signalling for T-ADS is via the Visited Mobile Switching Centre, VMSC1 303 in the CS network to which the originating UE 301 is anchored, and then via a Gateway Mobile Switching Centre, GMSC1 304 to MGCF 305, I-CSCF 306, S-CSCF 307 and eventually to Domain Selection AS 308 (e.g. an SCC AS) in the home IMS network of the terminating UE 302. To enable the access selection the AS 308 accesses data relating to the terminating UE 302 from the Home Subscriber Server, HSS, 309. To complete the Terminating procedure the signalling is then routed back through the IMS via S-CSCF 307, I-CSCF 306 and MGCF 305 to GMSC2 310 and VMSC2 311 to which terminating UE 302 is anchored in the CS network.
Analysis of the B-number (of the terminating UE 302) will determine whether or not the terminating UE is in the CS domain. This will be the case if the B-number cannot be resolved by ENUM, or if the B-number is within a number range for another operator that is not classified as a IMS operator.
Possible solutions to reduce the amount of unnecessary signalling that have been proposed include upgrading the Home Location Register, HLR 312 to perform the terminating domain selection. However, the HLR and HSS databases are usually deployed independently of each other and the lack of a uniform interface means it is difficult to query between HLR and HSS. Therefore this solution is not practical, at least until such time as there is a unified storage and query between the HLR and IMS HSS.